1. Field of the Invention
The present invention relates to computer systems, and deals more particularly with methods, systems, computer program products, and methods of doing business for providing improved identification of the resources and data instances that are to be managed by one or more management systems.
2. Description of the Related Art
Systems management software needs to address elements of the information technology (“IT”) environment that it manages. These elements are also referred to herein as “managed resources” or just “resources”. Each resource is unique, and when managing resources with systems management software, it is necessary that the resources are uniquely identifiable and addressable. For example, it may be desirable for the management system to alter the configuration of a resource. The management system therefore needs the ability to uniquely identify and address that resource. A management system may also perform functions related to fault or failure management. For example, a hardware device may fail, causing an event notification to be generated and sent to the management system. Or, a software application may generate an event notification, indicating that it has encountered some type of error situation. In order to process these generated events, it is necessary to uniquely identify the hardware devices and software applications (and other resources, as applicable) that are managed by the management system.
Managed resources are typically characterized by hierarchically-structured resource types. For example, an enterprise's resources might be broken down into hardware and software resources at a top level of the hierarchical structure, and the hardware resources might be further broken down by particular types of devices, or perhaps by hardware vendor or other category, while the software resources may be further broken down by target user group, software vendor, or other category. A number of intermediate levels may be defined within the hierarchical structure, and individual resources are then found at the lowest level.
The characteristics of each resource type must be defined so that a management system knows what properties the resources of this type have. The characteristics may be described using object-oriented (“OO”) technology. In this approach, a resource type is modeled as a class, and an individual resource is modeled as an instance of its corresponding class. One advantage of using OO technology is that resource types having similar characteristics can share a common “base class”. Management applications can then be written to the interface of the base class rather than to the interface of each individual resource class, which in turn increases the reusability and portability of the application software.
Because the resources are real elements of the IT environment, it may happen that a particular resource is within the management scope of more than one management system, in which case all of the management systems need the ability to uniquely identify that resource. Furthermore, it may be necessary to pass the identity of one or more resources between management systems. Therefore, a given resource should be uniquely identifiable in a manner that allows it to retain its unique identity across management system boundaries.
In the prior art, the identity of a resource is typically assigned in one of two ways. In a first approach, a resource identity is assigned by an agent being used by a management system to access the resource. In this approach, sometimes referred to as an “opaque key” approach, the format of the identity is opaque to all consumers except the agent that originally created it. For example, the agent might generate an internally-meaningful handle or other identifier with which it identifies the resource, where that identifier is used as an index into a locally-maintained mapping between identifiers and actual resources. Or, the agent might use some private structure to encode a resource's identity, where this agent knows how to parse the private structure to determine the referenced resource. The key disadvantage of this approach is that the identity is only useful when the creating agent is used for access to the resource, making it impossible for either an end user or another management system to recreate the identity of the resource. This severely limits interoperability in an environment in which there is more than one management system.
In a second prior art approach, sometimes referred to as an “natural key” approach, some set of one or more properties that uniquely identify a specific type of resource are designated as “key properties” or “identity properties”. All access to instances of that type of resource must therefore specify the values of each key property to identify the desired instance. A key disadvantage of this approach is that, in an OO system, only classes that have the same identity mechanism can be treated the same. Or, stated in OO terms, only classes with the same identity mechanism can be manipulated polymorphically. This creates a conflict when assigning key values. That is, to facilitate polymorphic access, keys should be defined near the root of the inheritance hierarchy in which the classes are defined. But, the values of the keys must be passed to the agents that will actually interact with the resource instances, and an agent must be able to use the identity it is passed (e.g., in a management request message) to find the target resource instance. This means that the keys must map to those properties in the real IT environment that identify a resource of a specific type. This requirement for identifying actual resources tends to force declaration of keys down to the leaf classes, or bottom, of the inheritance hierarchy. When key properties are located at the leaf classes, then classes between the leaves and the root are effectively unmanageable because there is no means to address class instances.
What is needed are techniques for identifying managed resources that avoid the limitations of prior art approaches.